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Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   When experimenting with or extending protocols, it is often necessary
   to use some sort of protocol number or constant in order to actually
   test or experiment with the new function, even when testing in a
   closed environment.  This document reserves some ranges of numbers
   for experimentation purposes in specific protocols where the need to
   support experimentation has been identified, and it describes the
   numbers that have already been reserved by other documents.
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1.  Introduction

   [RFC3692] recommends assigning option numbers for experiments and
   testing.  This document documents several such assignments for the
   number spaces whose IANA considerations are documented in [RFC2780].
   This document generally follows the form of [RFC2780].

   When using these values, carefully consider the advice in Sections 1
   and 1.1 of [RFC3692].  It is not appropriate to simply select one of
   these values and hard code it into a system.

   Note: while [RFC3692] says that it may not be necessary to allocate
   values for UDP and TCP ports, Sections 6 and 7.1 explicitly reserve
   ports for this purpose to avoid any possible conflict.

2.  Fields in the IPv4 Header

   The IPv4 header [RFC0791] contains the following fields that carry
   values assigned by the IANA: Version, Type of Service, Protocol,
   Source Address, Destination Address, and Option Type.

2.1.  IP Version Field in the IPv4 Header

   The Version field in IPv4 packets is always 4.

2.2.  IPv4 Type of Service Field

   [RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to
   either '0' or '1') as Experimental/Local Use, so no additional code
   points should be needed.  The Explicit Congestion Notification (ECN)
   field [RFC3168] has no free code points to assign.

2.3.  IPv4 Protocol Field

   [RFC3692] allocates two experimental code points (253 and 254) for
   the IPv4 Protocol field.

2.4.  IPv4 Source and Destination Addresses

2.4.1.  IPv4 Unicast

   No experimental IPv4 addresses are defined.  For certain experiments,
   the address ranges set aside for Private Internets in [RFC1918] may
   be useful.  It is not appropriate to use other special-purpose IPv4
   addresses [RFC3330] for experimentation.
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   At the time of this writing, some Internet Registries have policies
   allowing experimental assignments from number spaces that they
   control.  Depending on the experiment, the registry, and their
   policy, this may be an appropriate path to pursue.

2.4.2.  IPv4 Multicast

   The globally routable group 224.0.1.20 is set aside for
   experimentation.  For certain experiments, the administratively
   scoped multicast groups defined in [RFC2365] may be useful.  This
   document assigns a single link-local scoped group, 224.0.0.254, and a
   single scope-relative group, 254.

2.5.  IPv4 Option Type Field

   This document assigns a single option number, with all defined values
   of the "copy" and "class" fields, resulting in four distinct option
   type codes.  See Section 8 for the assigned values.

3.  Fields in the IPv6 Header

   The IPv6 header [RFC2460] contains the following fields that carry
   values assigned from IANA-managed name spaces: Version, Traffic
   Class, Next Header, Source and Destination Address.  In addition, the
   IPv6 Hop-by-Hop Options and Destination Options extension headers
   include an Option Type field with values assigned from an IANA-
   managed name space.  The IPv6 Routing Header contains a Type field
   for which there is not currently an explicit IANA assignment policy.

3.1.  IP Version Field in the IPv6 Header

   The Version field in IPv6 packets is always 6.

3.2.  IPv6 Traffic Class Field

   [RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to
   either '0' or '1') as Experimental/Local Use, so no additional code
   points should be needed.  The ECN field [RFC3168] has no free code
   points to assign.

3.3.  IPv6 Next Header Field

   [RFC3692] allocates two experimental code points (253 and 254) for
   the IPv6 Next Header field.
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3.4.  IPv6 Source and Destination Addresses

3.4.1.  IPv6 Unicast Addresses

   [RFC2928] defines a set of IPv6 addresses for testing and
   experimental usage:

      The block of Sub-TLA IDs assigned to the IANA (i.e.,
      2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and
      experimental usage to support activities such as the 6bone, and
      for new approaches like exchanges.

   However, at this writing, there are no RFC3692-style experimental
   IPv6 addresses assigned.  [HUSTON05] creates an IANA registry that
   may in the future contain such assignments.  For certain experiments,
   Unique Local Addresses [RFC4193] may be useful.  It is not
   appropriate to use addresses in the documentation prefix [RFC3849]
   for experimentation.

   At the time of this writing, some Internet Registries have policies
   allowing experimental assignments from number spaces that they
   control.  Depending on the experiment, the registry, and their
   policy, this may be an appropriate path to pursue.

3.4.2.  IPv6 Multicast Addresses

   The group FF0X::114 is set aside for experimentation at all scope
   levels.  Smaller scopes may be particularly useful for
   experimentation, since they are defined not to leak out of a given
   defined boundary, which can be set to be the boundary of the
   experiment.  For certain experiments, other multicast addresses with
   the T (non-permanently-assigned or "transient" address) bit [RFC4291]
   set may be useful.

3.5.  IPv6 Hop-by-Hop and Destination Option Fields

   This document assigns a single option type, with all possible values
   of the "act" and "chg" fields, resulting in eight distinct option
   type codes.  See Section 8 for the assigned values.

3.6.  IPv6 Routing Header Routing Type

   This document assigns two values for the Routing Type field in the
   IPv6 Routing Header, 253 and 254.
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4.  Fields in the IPv4 ICMP Header

   This document assigns two ICMPv4 type numbers, 253 and 254.  ICMPv4
   code values are allocated per type, so it's not feasible to assign
   experimental values in this document.

5.  Fields in the IPv6 ICMP Header

   [RFC4443] includes experimental ICMPv6 type values for Informational
   (200, 201) and Error (100, 101) message types.  ICMPv6 code values
   are allocated per type, so it's not feasible to assign experimental
   values in this document.

5.1.  IPv6 Neighbor Discovery Fields

   The IPv6 Neighbor Discovery header [RFC2461] contains the following
   fields that carry values assigned from IANA-managed name spaces:
   Type, Code, and Option Type.

5.1.1.  IPv6 Neighbor Discovery Type

   The Neighbor Discovery Type field is the same as the ICMPv6 Type
   field.  See Section 5 for those code points.

5.1.2.  IPv6 Neighbor Discovery Code

   The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no
   experimental code points are necessary.

5.1.3.  IPv6 Neighbor Discovery Option Type

   This document assigns two IPv6 Neighbor Discovery Option Types, 253
   and 254.

6.  Fields in the UDP Header

   Two system ports, 1021 and 1022, have been reserved for
   experimentation for UDP and TCP.
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7.  Fields in the TCP Header

7.1.  TCP Source and Destination Port Fields

   Two system ports, 1021 and 1022, have been reserved for
   experimentation for UDP and TCP.

7.2.  Reserved Bits in TCP Header

   There are not enough reserved bits to allocate any for
   experimentation.

7.3.  TCP Option Kind Field

   Two TCP options, 253 and 254, have been reserved for experimentation
   with TCP Options.

8.  IANA Considerations

   The new assignments are summarized below.


   IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local
   Network Control Block section) (Section 2.4.2)

   Group Address Name
   ------------- ----------------------------
   224.0.0.254   RFC3692-style Experiment (*)


   IPv4 Multicast Addresses (multicast-addresses relative addresses
   section) (Section 2.4.2)

   Relative Description
   -------- ----------------------------
   254      RFC3692-style Experiment (*)


   IPv4 Option Numbers (ip-parameters initial section) (Section 2.5)

   Copy Class Number Value
   ---- ----- ------ -----
      0     0     30    30
      0     2     30    94
      1     0     30   158
      1     2     30   222
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   IPv6 Option Types (ipv6-parameters Section 5.b.)  (Section 3.5)

   HEX         act  chg  rest
   ----        ---  ---  -----
   0x1e         00   0   11110
   0x3e         00   1   11110
   0x5e         01   0   11110
   0x7e         01   1   11110
   0x9e         10   0   11110
   0xbe         10   1   11110
   0xde         11   0   11110
   0xfe         11   1   11110


   IPv6 Neighbor Discovery Option Formats (icmpv6-parameters)
   (Section 5.1.3)

   Type Description
   ---- ------------------------------
   253  RFC3692-style Experiment 1 (*)
   254  RFC3692-style Experiment 2 (*)


   IPv6 Routing Header Routing Types (ipv6-parameters Section 5.c.)
                             (Section 3.6)

   Type Description
   ---- ------------------------------
   253  RFC3692-style Experiment 1 (*)
   254  RFC3692-style Experiment 2 (*)


   ICMPv4 Type Numbers (icmp-parameters) (Section 4)

   Type Name
   ---- ------------------------------
   253  RFC3692-style Experiment 1 (*)
   254  RFC3692-style Experiment 2 (*)


   System Port Numbers (port-numbers) (Sections 6 and 7.1)

   Keyword Decimal  Description
   ------- -------- ------------------------------
   exp1    1021/udp RFC3692-style Experiment 1 (*)
   exp1    1021/tcp RFC3692-style Experiment 1 (*)
   exp2    1022/udp RFC3692-style Experiment 2 (*)
   exp2    1022/tcp RFC3692-style Experiment 2 (*)
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   TCP Option Numbers (tcp-parameters) (Section 7.3)

   Kind Length Meaning
   ---- ------ ------------------------------
   253  N      RFC3692-style Experiment 1 (*)
   254  N      RFC3692-style Experiment 2 (*)


   Each of these registrations is accompanied by the following footnote:

   (*) It is only appropriate to use these values in explicitly-
       configured experiments; they MUST NOT be shipped as defaults in
       implementations.  See RFC 3692 for details.

9.  Security Considerations

   Production networks do not necessarily support the use of
   experimental code points in IP headers.  The network scope of support
   for experimental values should carefully be evaluated before
   deploying any experiment across extended network domains, such as the
   public Internet.  The potential to disrupt the stable operation of
   the network hosting the experiment through the use of unsupported
   experimental code points is a serious consideration when planning an
   experiment using such code points.

   Security analyzers such as firewalls and network intrusion detection
   monitors often rely on unambiguous interpretations of the fields
   described in this memo.  As new values for the fields are assigned,
   existing security analyzers that do not understand the new values may
   fail, resulting in either loss of connectivity, if the analyzer
   declines to forward the unrecognized traffic, or in loss of security
   if it does forward the traffic and the new values are used as part of
   an attack.  Assigning known values for experiments can allow such
   analyzers to take a known action for explicitly experimental traffic.

   Because the experimental IPv4 options defined in Section 2.5 are not
   included in the IPsec AH [RFC4302] calculations, it is not possible
   for one to authenticate their use.  Experimenters ought to keep this
   in mind when designing their experiments.  Users of the experimental
   IPv6 options defined in Section 3.5 can choose whether or not the
   option is included in the AH calculations by choosing the value of
   the "chg" field.

   When experimental code points are deployed within an administratively
   self-contained network domain, the network administrators should
   ensure that each code point is used consistently to avoid
   interference between experiments.  When experimental code points are
   used in traffic that crosses multiple administrative domains, the
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   experimenters should assume that there is a risk that the same code
   points will be used simultaneously by other experiments and thus that
   there is a possibility that the experiments will interfere.
   Particular attention should be given to security threats that such
   interference might create.
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